身為軟體公司的經營者，一定會遇到在開發軟體的過程中，為了趕專案進度或滿足業務需求，採取快速解法，解法可能不是非常好的時候，就會產生技術債。這些決策在短期內也許是合理的，透過犧牲一些工藝上的要求達成交付目標，然而缺乏後續的處理或是最佳化，這些技術債就會越來越大，變成阻礙開發效率與系統穩定性的絆腳石。

技術債之所以棘手，在於它不像財務中的債務一樣，有清楚的金額和利率，以及還款期限。但是技術債並沒有很容易理解與量化的方式，卻又有利息。所謂的利息，就是當這次的程式碼品質下降，可能是複製貼上程式碼，可能是架構上沒有按照標準進行開發時，所累積下來的技術債，使得團隊後面需要花更多的工時才能完成時，這部分是「利息」。衡量技術債的方式通常不會只有一種指標，而是多角度的組合。最直接的是透過團隊的開發效率的下降程度，來觀察如果新增一個小功能需要比過去更多的時間，可能系統中存在著技術債。另一種方式就是透過靜態工具，例如 SonarQube 或是 Linter，進行靜態分析來量化程式碼複雜度、重複率或不合規的地方。品質管理中的陷修復率與事故發生頻率，也能拿來使用，間接判斷技術債的規模有多大。

管理技術債的第一步，要想辦法量化或是描述什麼叫做技術債。然後將技術債的處理機制建立起來，例如缺少測試時什麼時候補測試的程式，或是在架構上不一樣的地方註記，後面處理。

衡量技術債的目的是為了讓經營者知道，當今天選擇業務價值之時，有一種方法，可知道該選擇的價值，是不是真的讓業務價值 > 技術債。